A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.
The present application relates generally to cryptographic systems and, more particularly, to methods for messaging server-based management and enforcement of crypto policies.
With each passing day, more and more computers are connected together through pervasive open networks, such as the Internet, Wide Area Networks (WANs), and the like. With the ever-increasing popularity of such environments comes the need for exchanging messages and other documents in a secured fashion over an open communication network. To this end, some sort of cryptographic system is usually employed.
Generally, cryptographic systems use either xe2x80x9csecret-keyxe2x80x9d encryption or xe2x80x9cpublic keyxe2x80x9d encryption. In xe2x80x9csecret-keyxe2x80x9d encryption, a single key is used for both encryption and decryption. Consider, for example, a user (sender) who wants to send an electronic mail or xe2x80x9ce-mailxe2x80x9d message to a colleague (recipient) in a secured manner, such that no one who intercepts the message will be able to read it. If the sender employs a cryptographic xe2x80x9csecret keyxe2x80x9d to encrypt the message, the recipient, in turn, must also use the same key to decipher or decrypt the message. As a result, the same key must be initially transmitted via secure channels so that both parties can know it before encrypted messages can be sent over insecure channels. This is typically inconvenient, however. A better approach is, therefore, sought.
Public key cryptography overcomes the problem by eliminating the need for a single xe2x80x9csecretxe2x80x9d key. As illustrated in FIG. 1A, each user of a public key cryptographic system has two mathematically-related keys, a xe2x80x9cpublic keyxe2x80x9d and a secret or xe2x80x9cprivate key.xe2x80x9d Operating in a complementary fashion, each key in the pair unlocks the code that the other key makes. Knowing the public key does not help deduce the corresponding private key, however. Accordingly, the public key can be published and widely disseminated across a communications network, such as the Internet, without in any way compromising the integrity of the private key. Anyone can use a recipient""s public key to encrypt a message to that person, with the recipient, in turn, using his or her own corresponding private key to decrypt the message. One""s private key, on the other hand, is kept secret, known only to the user.
Keys are typically stored on xe2x80x9ckeyrings.xe2x80x9d Public keys, including a user""s own as well as those of colleagues"", are stored in a xe2x80x9cpublic keyringxe2x80x9d file. A user""s private key is, in a similar fashion, stored in a xe2x80x9cprivate keyringxe2x80x9d file. Each key pair has a User ID (such as the owner""s name and e-mail address) so that the user and the user""s colleagues can identify the owners of keys. Each private key also has a passphrase, or verbose password, that protects it. No one but a message""s intended recipient can decrypt the message, not even the person who originally encrypted the message, because no one else has access to the private key necessary for decrypting the encrypted message.
Since public key cryptography provides privacy without the need for the same kind of secure channels that conventional secret key encryption requires, it is commonly employed to send secured messages and other documents from one individual to another across a network or other communication channel, including the Internet. An example of its use in a commercial product today includes PGP(trademark), available from Pretty Good Privacy, Inc. of Santa Clara. Calif.
Keys are also used to digitally sign a message or file and, in a complementary manner, to verify a digital signature. These xe2x80x9cdigital signaturesxe2x80x9d allow authentication of messages. When a user signs a message, a cryptographic program uses that user""s own private key to create a digital signature that is unique to both the contents of the message and the user""s private key. Any recipient can employ the user""s public key to authenticate the signature. Since the signer, alone, possesses the private key that created that signature, authentication of a signature confirms that the message was actually sent by the signer, and that the message has not been subsequently altered by anyone else. Forgery of a signed message is computationally infeasible.
By way of summary, FIG. 1B illustrates the functions for which public and private keys are used when sending and receiving messages. When keys are used to secure files stored on a user""s own computer or local network server, the user is both the xe2x80x9csenderxe2x80x9d (the person who saves the file) and the xe2x80x9crecipientxe2x80x9d (the person who opens the file).
Cryptographic systems, including ones implementing public key cryptography, are described in the technical, trade, and patent literature. For a general description, see e.g., Schneier, Bruce, Applied Cryptography, Second Edition, John Wiley and Sons, Inc., 1996. For a description focusing on the PGP(trademark) implementation of public key cryptography, see e.g., Garfinkel, Simon, PGP: Pretty Good Privacy, O""Reilly and Associates, Inc., 1995. The disclosures of each of the foregoing are hereby incorporated by reference.
The deployment of strong cryptography within an organization forces some important business policy issues to be managed. As with all strong crypto, the key(s) to which the data is encrypted must be available or else the data is totally unrecoverable. Most organizations find this risk unacceptable. For instance, a company might be (legally) required to be able to provide copies of e-mail that originated within its network. Accordingly, most organizations take steps to ensure that any corporate information is always recoverable by the company.
One way to accomplish this is to escrow all of the encryption keys within an organization. This solution has its own disadvantages and policy concerns attendant with other key escrow approaches. Another method is to employ a xe2x80x9cmessage recover agentxe2x80x9d that is designed to encrypt data to a designated recipient (i.e., the user""s company). Encryption client software (e.g., PGP) can readily be configured to support this recovery mechanism. However, it is possible for users to make mistakes, innocent and otherwise. A user""s act of downloading the freeware PGP client and running it on a corporate desktop would undermine the corporate policy, for instance. Enforcement of recovery policies at the client is awkward at best. Hence, a better approach is sought.
Since encrypting e-mail is the most common reason for organizations to deploy strong crypto, the messaging gateways are the most secure point to enforce a corporation""s crypto policy. It is reasonable to place the enforcement mechanism at such a point, therefore. What is needed is a system providing management and enforcement methodologies that afford system administrators secure and control access to the various servers throughout one""s organization. The present invention fulfills this and other needs.
The present invention comprises a system providing a xe2x80x9cPolicy Management Agentxe2x80x9d which works in conjunction with a standard mail server, such as an SMTP (Simple Mail Transport Protocol) mail server, to ensure that outgoing (and, optionally, incoming) e-mail adheres to the policies that are specified for a given site. The Agent intercepts e-mail normally bound for the mail server and checks to make sure that it conforms with policies configured for one""s site (e.g., corporate site). If the e-mail adheres to the policies for the site, it is forwarded to the mail server where it is routed to the intended recipient. If the e-mail does not adhere to the policies specified for the site, a message of one""s choosing is sent to the client indicating that the e-mail was rejected.
In an exemplary embodiment, the Policy Management Agent for SMTP provides the following features:
(1) Makes sure that e-mail has been encrypted using certain designated recovery keys. Only those messages which have been encrypted to the required keys are allowed to pass through the gateway.
(2) Ensures that all e-mail messages are encrypted before allowing them to be delivered. One can also specify that e-mail should not be encrypted from certain sites.
(3) Specifies whether e-mail must be signed or not before it is allowed to pass the policy requirement. The Agent can also reject e-mail that has been encrypted using certain keys which are designated as forbidden.
(4) Specifies whether conventional encryption is allowed.
(5) Maintains a log file listing all of the attempts to route e-mail along with a description of the outcome.
In operation, the system initializes a global configuration state. This step is followed by initialization of the proxy subsystem (i.e., Agent). Now the Agent can monitor e-mail: the Agent waits for a client connection. Specifically, the Agent waits to xe2x80x9ccapturexe2x80x9d a message body. The particular message body is employed to invoke PGP runtime calls from the PGPsdk cryptosystem runtime engine (available from Network Associates, Inc.). The PGP runtime engine builds a status list for the message, including information about:
(1) encryption recipient count (encryptionrecipientcount)
(2) list of encryption keyids (i.e., key IDs)
(3) conventional encryption recipient count (conventionalencryptionrecipientcount)
(4) number of signed sections
Based on the foregoing information, the Policy Management Agent may enforce specified crypto policies on the message. In an exemplary embodiment, policies or rules include:
(1) message must/must not/may be encrypted
(2) message must/must not/may be signed (mutually exclusive with previous)
(3) if encrypted, message must be encrypted to one of the following sets of keys
(4) if encrypted, message must not be encrypted to any of the following keys
(5) if encrypted, convention encryption may/may not be used
The policies can be applied to certain groups/entities based on their network location (i.e. Internet Protocol or IP address).
If a policy violation occurs, the event is logged in a logfile, and the message is not forwarded to the xe2x80x9crealxe2x80x9d messaging gateway. A configurable message, which informs the user why his message was rejected, is returned to the user. Thereafter, the system may perform cleanup and await another client connection.